View figure.
This section introduces TN3270 and summarizes the TN3270E server function implemented in Network Utility.
Many companies today are considering the consolidation of their WAN traffic onto a single IP-only backbone. At the same time, other companies are simplifying their workstation configurations and attempting to run only the TCP/IP protocol stack at the desktop. However, most of these companies still require access to SNA application hosts.
TN3270 meets these requirements by allowing you to run IP from the desktop over the network and attach to your SNA host through a TN3270 server. The clients connect to the server using a TCP connection. The server provides a gateway function for the downstream TN3270 clients by mapping the client sessions to SNA dependent LU-LU sessions that the server maintains with the SNA host. The TN3270 server handles the conversion between the TN3270 data stream and an SNA 3270 data stream.
To deploy a TN3270 solution, you install TN3270 client software on desktop workstations13 and TN3270 server software in one of several places discussed below. Client software is available from IBM and many other vendors, and runs on top of the TCP/IP stack in the workstation. A given client product provides one of two possible levels of standards support:
These clients conform to RFC 1576 (TN3270 Current Practices) and/or RFC 1646 (TN3270 Extensions for LU name and Printer Selection).
These clients conform to RFC 1647 (TN3270 Enhancements), and RFC 2355 (TN3270 Enhancements).
A server implementation that can support TN3270E clients is called a TN3270E server.
The TN3270 server function can be placed in a variety of products and positions within a network, including:
IBM and several other vendors provide host TN3270 server software that sits on top of the host TCP/IP stack and connects within the host to VTAM.
IBM and other vendors provide TN3270 server function in networking hardware products. You can place these products directly adjacent to the SNA host, or at any position in the network where you have SNA connectivity to the host. If you are using IBM routers (2210 or 2216) or Network Utilities, and your host is running APPN, you can use Enterprise Extender technology to place the server at any position where you have IP connectivity to the host.
IBM and other vendors provide TN3270 server software products that you install on mid-range servers that use operating systems such as AIX, OS/2, or Windows/NT. You can place these products at any position in the network where you have SNA connectivity to the application host.
The choice of TN3270 server product and network position is a complex one, involving such factors as:
Network Utility provides a high-performing TN3270E server implementation that scales to large networks. By combining it with the Network Dispatcher feature, you can implement server redundancy and load sharing in large TN3270 installations. You can also place a Network Utility out into an SNA or IP network away from the data center and get the same advantages of scalability, incremental addition, and reduced impact of server failure.
The Network Utility implementation of TN3270E server supports these RFCs:
It can handle both base TN3270 and TN3270E clients at the same time.
As mentioned above, the path from a TN3270 client to the SNA host consists of two pieces:
The form of the SNA connection from the server to the host depends on how the server represents PUs and dependent LUs. When you are using Network Utility as your TN3270 server, you can configure either of two different ways to establish links and represent PUs and LUs to VTAM:
You set up Network Utility this way when you are not running APPN at the host. You configure a separate DLC-layer link to the host for every PU (maximum of 253 LUs). Multiple PUs require multiple parallel host links. SNA frames arriving at Network Utility on one of these links flow directly to the corresponding internal PU.
Subarea host links must be a single DLC-layer hop to the product providing the SNA subarea boundary function. Typically, this product is either NCP running in a FEP, or is VTAM itself in the host. The subarea link from the Network Utility can traverse bridges or other DLC-layer forwarding mechanisms (such as protocol converters or external DLSw routers). Network Utility supports the following link types for subarea host attachment:
You set up Network Utility this way when you are running APPN with its Dependent LU Server (DLUS) function at the host. You configure one DLC-layer link to the host to carry the DLUR-DLUS "pipe," even if you are defining multiple local PUs. SNA frames arriving at Network Utility on this link flow to the DLUR function, which redirects them to the correct internal PU.
When you are using DLUR, you can route through an APPN network using either ISR or HPR routing to reach the host. Network Utility supports the following link types as the "first hop" APPN link to the host:
Note especially that when using DLUR and HPR routing, you can place a Network Utility TN3270E server across an IP network from the SNA application host. Enterprise Extender maintains session-level class of service and transmission priority across the IP network.
This section covers general information about configuring Network Utility TN3270 server support. For specific example configurations, see page "Example Configurations".
In the Network Utility implementation of TN3270 server, all SNA functions are bundled within the APPN protocol. This means that even when you are configuring SNA subarea attachment and your SNA host is not running APPN, you must use the configuration and console services of the APPN protocol. In particular:
When you configure SNA subarea support, Network Utility does in fact still function as an APPN network node, but only on links to other APPN nodes. If the only ports and links you configure are those for SNA subarea host attachment, then the APPN function serves no purpose.
APPN and TN3270 server are fully configurable both from the Configuration Program and from the command line. From the Configuration Program, the TN3270 configuration parameters are always available. If you create a TN3270 configuration and download it to a Network Utility Model TX1, which does not support TN3270 server function, the Network Utility ignores the TN3270 part of the configuration. If you are working from the command line on a Model TX1, the commands for configuring and monitoring TN3270 simply do not appear on the APPN menus.
To change an APPN/TN3270 configuration from the Configuration Program, you make the change, transfer the configuration to the Network Utility, and reboot for it to take effect.
To change an APPN/TN3270 configuration from the command line, you move to talk 6, type p appn, and then issue the commands to make the change. You have two options for activating the change:
Depending on the configuration items you changed, APPN either makes the change immediately, or restarts APPN (but not the entire Network Utility) to activate the change. For the latter case, if you move to talk 5 and type p appn while APPN is restarting, you get the message APPN is not currently active. You can poll with talk 5 commands to see when the restart is complete.
When you configure Network Utility's TN3270 server function, you create a local LU name for every one of the potential concurrent client sessions the Network Utility is intended to support. The LU name you define in the Network Utility need not have any relation to LU names in VTAM.
When a TN3270 client connects to a server over TCP, it can request a specific LU name, or it can place a generic request for any LU of a certain type. If you are configuring a client to request a specific name, you specify one of the local names defined at the server (Network Utility), not a VTAM LU name.
Because a single Network Utility can support thousands of LUs with similar characteristics, it does not require you to individually configure each LU. Rather, you can create a large pool of implicit LUs to satisfy clients that do not request a particular LU name. You then add a small number of explicit LUs to satisfy the clients that do request a particular name14.
As you will see in the example configurations, you define implicit LUs in groups as you define each local PU. You specify an LU name mask, number of LUs and to which pool the LUs belong. To configure an explicit LU, you specify an LU name and an NAU address (2-254). When the Network Utility activates the configuration, it reserves the NAU addresses for explicit LUs, and then generates names for the implicit LUs using the group name mask and one of the available NAU addresses.
MAS V3.2 PTF01 introduced a number of significant functional enhancements in the area of LU definition and client mapping:
LU pooling is an enhancement to the TN3270E server function that makes it easier for you to configure some TN3270E networks. This function allows you to group SNA LUs into named "pools". TN3270E clients can then request a connection using the pool's name as an LU name. The TN3270E server will then choose an LU from the specified pool to serve the client's request.
The TN3270E server Client IP Address to LU Name Mapping function provides a mechanism for administrators to control client access to the TN3270E server's LUs.
Mapping enhances central administration by allowing the administrator to configure which SNA resources (LUs or Pool) client IP address or subnets will map to and use without modifying client configurations.
The dynamic definition of dependent LUs (DDDLU) is a VTAM facility that allows the logical units to be known by VTAM when they connect to VTAM, rather than during major node activation of the related PU.
If prompted by VTAM, the TN3270E server function will use DDDLU to create its local LUs in VTAM. Instead of sending all of the LU definition requests when the ACTPU is received, the server will wait until the LU actually needs to be defined. The LU definition will occur when a TN3270 client connects in and needs an LU that has not been defined to VTAM.
This enhancement allows you to define multiple TCP ports for the TN3270E server to "listen" on. This support allows clients to specify the SNA resource they want using a port number.
This enhancement allows you to specify whether the added port will negotiate to be a TN3270E server, as opposed to conforming only to the base TN3270E support. This is needed by some base TN3270 clients, who do not properly handle receiving initial TN3270 Extended negotiations.
Refer to the MAS V3.2 or later MAS Protocol Configuration and Monitoring Reference Volume 2 for more information on configuring these functions.
MAS V3.3 introduced Host Initiated DDLU:
Network Utility as a TN3270E server can be deployed in several configurations. For example, it can be placed either in the remote branch or in the data center. It can attach to the host via a traditional SNA subarea connection or it can use APPN. In the data center, it can be placed in a channel-attached configuration or it can be a stand-alone server that resides on the campus LAN (or ATM cloud) using the channel-attached connection provided by an existing IBM 3745/46 Communication Controller, 2216-400, 3172 Interconnect Controller, an OSA adapter, or an OEM gateway.
One of the most important elements of a TN3270 implementation is scalability. The Network Utility solution can scale to very large configurations while providing high availability and redundancy.
The following scenarios show you how to effectively utilize the Network Utility as a TN3270E server.
This scenario (shown Figure 12-1) shows a traditional SNA subarea network with all host access occurring through an IBM 3745/46 Communication Controller with the IBM Network Control Program (NCP). The Network Utility is installed to provide TN3270 server support for downstream workstations both in the local campus and in the remote sites. The Network Utility attaches to the host through the FEP via a normal subarea connection.
Up to 20 000 TN3270 sessions can be handled with a single Network Utility installed as shown in Figure 12-1. As your network grows, the solution can be scaled simply by adding more TN3270E server capacity via additional Network Utilities. You can also set up automatic load balancing among your TN3270E servers by installing a separate IBM router or Network Utility to serve as a Network Dispatcher. (See Highly Scalable, Fault-Tolerant TN3270E for an example of how to scale the network.)
Figure 12-1. TN3270 via a Subarea Connection through a 37xx
View figure.
The configuration of the TN3270E server function is very straightforward in this scenario. However, the following points are worth noting:
Note also these additional points relating to APPN and TN3270E server configuration:
For a complete look at the configuration parameters needed for this scenario, see Table 13-2.
This scenario, shown in Figure 12-2, is similar to the previous scenario except that here, the Network Utility attaches to the host through a LAN channel gateway such as an IBM 3172, an IBM 2216, an IBM 3746 with the Multiaccess Enclosure (MAE) or an OEM device. These gateways use External Communications Adapter (XCA) pass-through and do not provide the SNA boundary function normally provided by an NCP. With a gateway, this function is provided by VTAM.
If you have an existing gateway with a TN3270 server configured, you can use the Network Utility to offload the existing TN3270 workload or to provide additional TN3270 capacity as your network requirements grow.
An existing 2216 or a 3746 allows you to have multiple channel connections to the host while you can incrementally install Network Utilities for your TN3270E server requirements. The dynamic load balancing features of network dispatcher can be used to optimize efficiency.
Figure 12-2. TN3270 via a Subarea Connection through a LAN Gateway
View figure.
From the Network Utility perspective, the configuration of this scenario is identical to the previous one. The host definitions are also identical. For both scenarios, you just have to define the switched major nodes for the PUs in the TN3270E server.
This scenario is shown in Figure 12-3. Here, the Network Utility attaches to the host through the S/390 Open Systems Adapter (OSA). Like the previous gateway scenario, the SNA boundary function is in the host.
While the TN3270 server function can reside on the host itself, many customers prefer to offload this function externally to another platform. The Network Utility meets this requirement well by providing scalable, cost-effective TN3270E server function without changing your method of host attachment. This allows you to leverage your existing investments.
Figure 12-3. TN3270 via an OSA adapter
View figure.
From the Network Utility perspective, the configuration of this scenario is identical to the previous two.
TN3270E over subarea SNA over DLSw connection is used for eliminating a second router requirement in the remote nodes or branches. Without this function, you would need two routers in a branch to be able to run TN3270E Server over IP, as shown in Figure 12-4. With the TN3270E Server support on DLSw Subarea, two Network Utility boxes are not needed since DLSw and TN3270E supports are merged in a single Network Utility.
 View figure. |
As shown in Figure 12-5, TN3270E Server and DLSw are supported in a single Network Utility with Multiple PU's Subarea function. In this function, there is an APPN/DLSw interface within Network Utility. It is possible to run 58 link stations over this interface--in other words, you can run 58 SNA PU Type 2's. The new multiple PU's subarea function can run over Local or Remote DLSw. Local DLSw supports LSA ESCON connection, X.25 QLLC and SDLC links.
 View figure. |
This scenario, shown in Figure 12-6, is an extension of the one discussed in TN3270 via a Subarea Connection to an NCP. Here, the solution is scaled with multiple Network Utility devices to provide TN3270E server support for large 3270 environments. Also, a separate Network Utility is configured as a network dispatcher and deployed to provide load balancing16. The new Network Dispatcher Advisor for TN3270 allows the Network Dispatcher to collect load statistics from each Network Utility TN3270E server in real time to achieve the best possible distribution among the TN3270 servers.
The solution provides high availability in the event of a failure in one of the TN3270E servers. The server that the client session is dispatched to is transparent to the user. If a failure occurs, the sessions through that server are lost but the users simply log back on to the host through another Network Utility using the same destination IP address for the TN3270E server.
The Network Dispatcher function can also utilize redundant hardware, with a second Network Utility configured as a Network Dispatcher and serving as a backup to the primary one.
With this configuration, you can scale your TN3270E support to any size simply by adding additional TN3270E server capacity. You can do this incrementally and non-disruptively as your network requirements grow.
Figure 12-6. Highly Scalable, Fault-Tolerant TN3270E
View figure.
As far as the TN3270E server is concerned, the configuration is the same whether you have a Network Dispatcher or not. In fact, the TN3270E server is unaware that the traffic from the clients is being dispatched through another machine. See TN3270 via a Subarea Connection to an NCP for the basic configuration points for a TN3270E server. See Table 13-3 for the complete set of configuration parameters for the TN3270E servers for this scenario.
However, the IP addressing needs special attention in this configuration for high availability. In TN3270 via a Subarea Connection to an NCP, the TN3270E server was configured with the same address as the router ID (also the same address as the LAN interface). In a Network Dispatcher environment, the IP addressing is somewhat different.
A Network Dispatcher and one or more TN3270E servers form what is called a cluster. An IP address is defined for the cluster and workstations send their TN3270 packets to this IP address. The Network Dispatcher receives these packets and forwards them on to a server in the cluster for processing.
Because the Network Dispatcher does not alter the destination IP address of these packets, each TN3270E server also needs to be configured with this same IP address. However, you have to make sure that the TN3270E servers do not broadcast this address via OSPF or RIP to the network because you do not want these servers to respond to the cluster address. Only the Network Dispatcher should respond to the cluster address17.
The router must know the TN3270E server's IP address in order to forward packets to the server function. One way to make this address known to the router is to specify it to an interface as a secondary address. Figure 12-7 shows an example of this IP addressing scheme for the highly available, fault-tolerant TN3270 configuration depicted in Figure 12-6.
Figure 12-7. IP addressing for the Highly Scalable, Fault-Tolerant TN3270 Scenario
TN3270E Server #1 (TNA):
Internal address 172.128.252.3
Interface 0 172.128.2.3 (2nd address: 172.128.1.100)
Interface 1 172.128.1.3
OSPF Router ID 172.128.1.3
TN3270E Server 172.128.1.100 (same as cluster address)
TN3270E Server #2 (TNB):
Internal address 172.128.252.4
Interface 0 172.128.2.4 (2nd address: 172.128.1.100)
Interface 1 172.128.1.4
OSPF Router ID 172.128.1.4
TN3270E Server 172.128.1.100 (same as cluster address)
Network Dispatcher #1 (NDA):
Internal address 172.128.252.1
Interface 0 addrs 172.128.1.1
OSPF Router ID 172.128.1.1
Cluster address 172.128.1.100
Port 23
Server 1 172.128.1.3
Server 2 172.128.1.4
Network Dispatcher #2 (NDB):
Internal address 172.128.252.2
Interface 0 addrs 172.128.1.2
OSPF Router ID 172.128.1.2
Cluster address 172.128.1.100
Port 23
Server 1 172.128.1.3
Server 2 172.128.1.4
|
Note that the cluster address is assigned as a second IP address on interface 0 of the Network Utility machines. In this scenario, the LAN segment that interface 0 attaches to does not carry any IP traffic - only the SNA subarea traffic from the TN3270E server to the host.
The configuration of the Network Dispatchers is standard. For the complete set of configuration parameters needed for this scenario, see Table 13-4 for the primary network dispatcher. For differences from this configuration for the backup network dispatcher, see Table 13-5.
This scenario, shown in Figure 12-8, uses APPN to communicate with the host. The Network Utility uses APPN High Performance Routing (HPR) and establishes a Rapid Transport Protocol (RTP) session with the host. HPR is used all the way from the TN3270E server to VTAM. In case of a failure, this assures nondisruptive session switching to an alternate path if you have parallel gateways. This is especially important in Parallel Sysplex environments.
In addition, HPR is supported over IP through the Enterprise Extender feature of the Network Utility. This is important if you want to place your TN3270E server in a remote location and use IP to transport the APPN traffic back to your data center.
The channel gateway is an APPN network node performing APPN Automatic Network routing (ANR) for the RTP session between the Network Utility and the host.
Figure 12-8. TN3270 Via DLUR over APPN
View figure.
When connecting a TN3270E server to the host via APPN, you must configure DLUR support on the Network Utility. The DLUR feature extends to APPN nodes the support of T2.0 or T2.1 devices containing dependent LUs. The DLUR function on an APPN network node works in conjunction with a DLUS. The DLUS function is usually provided by VTAM, although it may reside in any part of a mixed APPN/subarea network.
The dependent LU flows (SSCP-PU and SSCP-LU) are encapsulated in a LU 6.2 pipe (CP-SVR) established between the DLUR APPN node and the DLUS SSCP. The CP-SVR pipe is made up of a pair of LU 6.2 sessions using a new CPSVRMGR mode between the DLUR and the DLUS. This pipe brings the SSCP function (in the DLUS) to the DLUR APPN node where it can be made available to attach T2.0/T2.1 nodes containing dependent LUs.
From a downstream workstation perspective, the TN3270E server appears the same whether that server is using SNA subarea or APPN to communicate with the host on the uplink. At the Network Utility, you configure the base TN3270 server parameters the same way as in the SNA subarea scenarios, but the way you configure the local PUs differs. Instead of associating each PU with a subarea link, you configure local PUs without any link association. The DLUR function is responsible for routing traffic on the DLUS-DLUR pipe to and from these local PUs.
APPN requires DLUR support to be configured in the Network Utility. DLUR is quite simple to configure with the only required parameter being the CP name of the DLUS, which is VTAM.
You have to make some additional host definitions for APPN and DLUR support. See Chapter 18, Sample Host Definitions for an example of these commands.
For a complete look at the configuration parameters needed for this scenario, see Table 13-6.
The previous configurations showed how the Network Utility can be deployed in the data center to centralize the TN3270E server function in your network. This configuration, shown in Figure 12-9, shows just one example of how the Network Utility can also be placed in a remote location to provide distributed TN3270E server capability.
In this configuration, the Network Utility is providing TN3270E server service to workstations in the remote location. As always with a TN3270 configuration, the workstations are using IP to communicate with the TN3270E server. The TN3270E server is using DLUR over an APPN connection back to the host in the data center.
In this example, the corporate WAN is a public Frame Relay network that carries IP traffic only. Therefore, the Network Utility is configured to use the Enterprise Extender feature which allows the APPN HPR traffic to be carried over the IP-only WAN.
The Enterprise Extender traffic is terminated at the host gateway, which decapsulates the HPR traffic and then passes the APPN traffic through the network node onto the MPC+ path to the host. This is a very fast, low-overhead packet-forwarding function, so a single gateway can handle a large amount of traffic.
Figure 12-9. Distributed TN3270E Server
View figure.
From a downstream workstation perspective, the TN3270E server appears the same whether it is in the remote branch or in the data center regardless of whether the upstream connection to the host is using SNA subarea or APPN. Therefore, the TN3270E server function in the Network Utility is configured exactly the same as in the previous scenarios.
APPN and DLUR are configured the same as in TN3270 Via DLUR over APPN with one exception, which is the port definition for APPN over the frame relay IP link. When configuring APPN to use HPR over IP (the Enterprise Extender feature), you specify a port type of IP. Then when adding the link station for this port, instead of specifying the MAC address of the adjacent FEP as was done in TN3270 Via DLUR over APPN, you specify the IP address of the other end of the HPR over IP network, which is the host gateway in this example18. The IP network is responsible for the delivery of the traffic to the host gateway over the best path available. You are assured a reliable transport because the connection between the TN3270E server and the host uses an RTP session.
This section introduces some of the ways in which you can monitor and manage the TN3270E server function.
| Note: | The monitoring functions described in this section assume that you are running MAS V3.2 or later operational code. MAS V3.2 introduced several new TN3270 monitoring commands, as well as a TN3270E submenu. |
To view currently running TN3270 server status from the command line, move first to talk 5 and enter p appn. If you get the message Protocol APPN is available but not configured, you need to complete your base APPN configuration and reboot Network Utility to activate APPN. As discussed in Configuring TN3270 Subarea under the APPN Protocol, you need APPN to be active even if you are using only TN3270 subarea connectivity.
Once you have reached the APPN monitoring prompt APPN >, type tn (short for "TN3270E") to reach the submenu for monitoring TN3270E server status.
The following commands are then available at the TN3270E > monitoring prompt:
If the server function is active, this command provides the following information:
Displays all currently active client connections (those with an active TCP connection).
Displays all the currently active connections that originated from the specified IP address.
Displays all currently active connections that are associated with the specified LU or pool name.
For each of the list connection commands, the following information is displayed for each session:
Besides the above list commands, a TN3270 server user needs to be able to query the status of other APPN or SNA resources on which the function depends. The following APPN monitoring commands are of general use:
If you are using DLUR for your host connection, the following commands are particularly useful:
To review your APPN configuration, move to talk 6 and type list all.
In general, APPN/TN3270 ELS messages are intended to capture debug and trace information for IBM support personnel. These functions have extensive logging and trace support, but the ELS messages themselves are tightly packed with low-level information.
Normally, you activate APPN/TN3270 tracing and logging under the direction of IBM support personnel. The general procedure is to enable some of a large list of possible traces as part of your APPN configuration. From the Configuration Program, see the APPN Node Services folder. From talk 6, use the set trace command. After you activate this configuration change, the output of these traces flows into a trace table in APPN memory, and also to ELS if you have APPN ELS messages active. Should you have a problem that requires activating traces, IBM support will provide detailed procedures to guide you in capturing debug information.
APPN generates SNA alerts for a variety of error conditions, and can forward alerts from other SNA devices. This support is described in SNA Alert Support. There are no alerts specific to the TN3270 server function, but alerts that a Network Utility itself generates may relate to SNA resources involved with TN3270.
From a VTAM or NetView/390 operator console, you can control the links, PUs, and LUs involved with TN3270 as described in NetView/390.
Network Utility supports an Internet Draft version of both of the forthcoming standard MIBs for TN3270 server function:
Network Utility support for these MIBs includes the ability to:
In addition, Network Utility supports the following IETF MIBs relating to APPN and SNA functions:
Network Utility supports the following IBM Enterprise-Specific MIBs relating to APPN functions:
These MIBs provide a comprehensive view of APPN and SNA resources within Network Utility, including those being used for TN3270.
The Nways Manager products discussed in IBM Nways Manager Products provide specialized statistical support for TN3270 response time monitoring, as well as the ability to view TN3270 server resources. To initiate response time monitoring, you select a group of one or more clients using an IP address and mask. For each group you define, the manager collects response time statistics into predefined time buckets (less than 1 second, 1 to 2 seconds, and so on). Using the collected information, you can view aggregate historical response time by group, or create custom reports that present the data in different graphical formats.
To view TN3270 resources and their status, you use specific panels that combine information from different tables within the base TN3270 MIB. To view APPN and SNA resources in general, you use specific panels that access information from the APPN MIBs. You can also use integrated browser support to view the information in any of these MIBs.
Nways Manager for AIX provides an APPN-level view of the topology of your network. You can discover participating APPN resources, view them, and view their status as color-coded icons. APPN protocol performance and error events (data and graph) are also provided. This application does not represent Branch Extender or Extended Border Node topologies.
You may use Dynamic Definition of Dependent LUs (DDDLU) to avoid duplicate definition of LUs in both VTAM and the TN3270E. DDDLU allows LUs to be defined in one place only--the Network Utility. In VTAM, you only need to define one or more PUs depending on the number of LUs you need. Implementation of DDDLU also eliminates the efforts of definitions and maintenance in VTAM for future LU definition requirements.
When a TN3270E client requests a connection using one of the LUs defined in the router, the router sends a Reply/PSID NMVT command to VTAM. In this command, the local address of the LU and device type information (3270) is sent to VTAM using the SSCP-PU session. VTAM then sees from the PU definition that there is no definition for the LU in question. At this time, VTAM creates the LU definition using the LUGROUP model statement for the parameter values and the LUSEED value for the dynamic name generation for the LU.
LUs which require specific LU names and 3270 printers on specific ports can also be defined under the same switched major node. See this sample below.
DDDPU VBUILD TYPE=SWNET
DDPU PU ADDR=02, x
IDBLK=077, x
IDNUM=22160, x
PUTYPE=2, x
USSTAB=US327X, x
LUGROUP=GROUP1, x
LUSEED=DDLU###, x
DLOGMOD=D4C32XX3 x
SALE01 LU LOCADDR=98, x 1
DLOGMOD=D4C32XX3, x
LOGAPPL=CICSA
SALEPRT LU LOCADDR=99, x 2
LOGMODE=SAL3287,
LOGAPPL=CICSA
|
The name specified for the LU in TN3270E Server (local LU) does not need to match the name generated by VTAM for the same LU. If the client wants to have a specific LU, instead of just selecting any LU from a pool, it must use the LU name that is specified in TN3270E. The host application, however, works with the LU name that VTAM generates dynamically. These two names are tied to each other via the local address of the LU.
Figure 12-10. TN3270E Server Running on ESCON Attached Network Utility, Using DDDLU
 View figure. |
The dynamic definition of LUs is done in VTAM exit routine Selection of Definitions for Dependent LUs (SDDLU). If you use the IBM supplied SDDLU exit program, then you need to specify the LUSEED parameter for name construction in the PU definition, in addition to the LUGROUP model major node. If you use an exit program of your own, you should follow its practices.
This concept is described in detail in SC31-8370, VTAM Network Implementation Guide, under the section entitled "Defining Dependent LUs Dynamically".
The LU can be explicit (as defined locally in TN3270E), in which case the client must specify an exact LU name in the workstation. The LU requested by the user (TN3270 client) can also be an implicit one, in which case it belongs to a pool of LUs.
IP address to LU name mapping is also supported for DDDLUs. In addition, you can have other explicit LUs, defined in different ways, under a different PU to be used for IP address to LU mapping.
In addition to DDDLU, another way to avoid duplicate LU definitions is Host Initiated Dynamic LU (HIDLU). HIDLU allows LUs to be defined in VTAM only. In Network Utility (or 2216) you only define a PU, or as many PUs you need, but no LUs for these PUs.
When a client requests to use such an LU, TN3270E sends VTAM a request to activate the PU and its LUs. When the VTAM-defined LUs are activated, the LU names will be conveyed to Network Utility in the ACTLU commands in Control Vector 0E.
LUs defined in this manner have the same name in both VTAM and the Network Utility.
To use HIDLU, you have to use parameter INCLUD0E=YES in the PU definition in VTAM. This function requires VTAM V4R4 with APAR OW25501 and OW31805. With HIDLU, you can only define display terminals. Printers are not supported. HIDLU definitions can be used at the same time with other locally (in the Network Utility) defined LUs, which can be implicit, explicit or DDDLU defined LUs.
Host On-Demand (HOD) allows Web browser clients to connect to SNA 3270 and 5250 host applications. The terminal emulation (TN3270 or TN5250) runs as a Java applet in the client's browser. Connection to a host application is made via a TN3270 (or TN5250) server.
Java applets are usually retrieved from a HOD server, which runs as a Web server.
Host On-Demand Client Caching allows an IBM 2216 or 2212 or Network Utility, acting as a TN3270 Server, to cache the HOD applets and serve them to client browsers upon request.
HOD Client Cache can offload the HOD Server and, if placed strategically, can load HOD pages and applets quicker to client workstations. Another advantage of using HOD Client Cache function is to distribute the load on specific lines/bandwidths within the network to eliminate the congestion. The function uses and is defined under Network Dispatcher feature, using either talk 6 or the configuration program. First, a cluster address is defined to Network Dispatcher, and then port number(s) and HOD Server addresses are defined under that cluster address.
The basic operating principle of HOD Client Cache is the following: The clients use the ND cluster address in their browsers, instead of the actual address of the HOD Server. When the request for HOD Server comes to the cluster address, port 80 (HTTP port number), Java applets required to establish the session will be transferred from the HOD cache. If the applets or other required pages are not in the cache of Network Utility, the router will connect to the HOD Server, download the items, store them in the cache and provide them to the client. Now that the pages and applets are in the cache, the next user will make a hit and get them directly from the cache. Therefore, this HOD Client Cache function on Network Utility helps to better utilize the network by distributing the Java applets on Network Utilities so that clients do not have to load these applets from the HOD Server. When using this function, no extra load is created on the HOD Server either, since the requests of Java applets are delivered by Network Utility.
Figure 12-11. Scenario With TN3270E Server and HOD Cache
 View figure. |
HOD Client Caching is only available together with TN3270E Server function.